Method and System for Reliable Multicast Data Transmission

ABSTRACT

Provided is a method and system for reliably multicasting a data transmission from a server to one or more clients, which may be connected via a control channel and a multicast data channel. In one example, the method includes sending a first data transmission to the clients over the multicast data channel. A response is received over the control channel from at least some of the clients. The response identifies data not received by the responding client. In some examples, the response may indicate that all the data was received. The server determines a minimum retransmission data set based on the responses. The minimum retransmission data set includes at least some of the data not received by the client during the first data transmission. The minimum retransmission data set is sent over the multicast data channel and received by the clients that did not receive it during the first data transmission.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. patent application No.10/621,699, filed Jul. 17, 2003, which is hereby incorporated byreference in its entirety.

BACKGROUND

This disclosure relates generally to multicast data transmission and,more specifically, to a method and a system for ensuring completetransmission of multicast files with minimum retransmissions.

A computer network generally has at least one computer (a server) thatprovides services to other computers (clients) via the network.Traditionally, network communications have employed a unicasttransmission model in which a separate connection is made between aserver and each of its clients. This model works particularly well wheneach client has unique demands of the server. However, when each clientis receiving the same data, multiple copies of the same informationpacket can flood the network, causing congestion and escalatingbandwidth requirements.

Multicasting may alleviate some of the problems associated withunicasting by enabling a server to transmit a single packet ofinformation that may be received by multiple clients who have requestedthe information. Multicast enabled switches and routers permit thesingle packet of information to be copied so that only a single packetneed be forwarded through each branch of the network to reach theclients requesting the information. Although multicasting may be used ina wide variety of applications in which large amounts of information arebeing sent to multiple clients, multicasting generally used forapplications in which many clients want the identical datasimultaneously. Such applications may include live audio or videotransmissions, multi-user games, and real-time stock tickers.

Despite the benefits of multicasting for some applications, presentimplementations of multicasting do not enable a server to receiveperformance information back from clients, and therefore, transmissionreliability may be sacrificed. Current methods of multicasting may alsoresult in unrecoverable data loss.

Therefore, what is needed is an improved method and a system for thecomplete transmission of multicast files. It is also desirable tomaintain efficiency by minimizing retransmissions.

SUMMARY

Provided is a method and system for reliably multicasting a datatransmission from a server to one or more clients. The server andclients may be connected via a control channel and a multicast datachannel. In one embodiment, the method comprises sending a first datatransmission to the clients over the multicast data channel andreceiving a response over the control channel from at least one of theclients identifying data not received by the client during the firstdata transmission. A minimum retransmission data set is determined basedon the response, wherein the minimum retransmission data set includes atleast a portion of the data not received by the client during the firstdata transmission. The minimum retransmission data set is sent over themulticast data channel.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a flowchart illustrating one embodiment of a method for datamulticasting in the network of FIG. 1.

FIG. 2 is a diagram of an exemplary computer and network environment inwhich the methods of FIGS. 2, 3 a, and 3 b may be executed.

FIG. 3 a is a flowchart illustrating another embodiment of a method fordata multicasting in the network of FIG. 1.

FIG. 3 b is a flowchart illustrating a file reception process of FIG. 3a.

FIG. 4 is a scorecard that may be used with the method of FIGS. 3 a and3 b.

DETAILED DESCRIPTION

This disclosure relates generally to multicast data transmission and,more specifically, to a method and a system for ensuring completetransmission of multicast files with minimum retransmissions. It isunderstood, however, that the following disclosure provides manydifferent embodiments or examples. Specific examples of components andarrangements are described below to simplify the present disclosure.These are, of course, merely examples and are not intended to belimiting. In addition, the present disclosure may repeat referencenumerals and/or letters in the various examples. This repetition is forthe purpose of simplicity and clarity and does not in itself dictate arelationship between the various embodiments and/or configurationsdiscussed.

Referring to FIG. 1, in one embodiment, a method 100 enables a computer(e.g., a server) to efficiently provide identical information to aplurality of other computers (e.g., clients). As will be described ingreater detail in FIG. 2, the server may be connected to the clients viaa control channel and a data channel. In step 102, the server transmitsone or more files over the data channel using a multicast transmission.In step 104, the server receives a response from the clients over thecontrol channel. If a file is not received in its entirety by one ormore clients, the response may identify which parts of the file were notreceived by each client. If a client received the entire file, it mayeither not respond to the server or may indicate that the entire filewas received, depending on the particular implementation of the method100. For example, if a client chooses not to acknowledge the successfulreception of the file, the lack of acknowledgement may be interpreted asan acknowledgement by the server after a predefined amount of time hasexpired with no further communication from the client.

In step 106, a determination is made (based on step 104) as to whethereach file was received by each client in its entirety. If each file wasreceived, the method 100 ends. However, if each file was not received,the method 100 continues to step 108, where the server determines aminimum retransmission data set based on the response of step 104. Inthe present example, the minimum retransmission data set includes eachpart of the file that was not received by the clients. In step 110, theserver then sends the minimum retransmission data set to the clients.The minimum retransmission data set may be sent to all the clients oronly to the clients who indicated that they were missing data. Themethod 100 then returns to step 106. Steps 106-110 may be repeated untilall clients have received the data transmitted in step 102.

Referring now to FIG. 2, an exemplary communications system 200, withinwhich the method 100 of FIG. 1 may be executed, is illustrated. Thecommunication system 200 includes a computer network 202. Connected tothe computer network 202 are a server 204 and one or more clientcomputers 206 (“clients”). Additional servers, which may include hostand proxy servers, may be connected to the computer network 202 toexpand the services provided by the communications system 200. Thecomputer network 202 may be, for example, the public Internet or aprivate intranet, and may include a plurality of routers 208, switches210, and/or other equipment for connecting the server 204 to the clients206. Further, the computer network 202 may include, for example, asatellite network, a terrestrial network, or a combination of the two.The routers 208 and switches 210 may be multicast enabled. It isunderstood that, in some embodiments, the client computers 206 may actas a server to other client computers 206.

The server 204 and the clients 206 may be connected to the network by acontrol channel 212 and a data channel 214. As one example, thecommunications system 200 may utilize a satellite link as the datachannel 214 and may use a terrestrial connection as the control channel212. The control channel, which may use a protocol such as atransmission control protocol (TCP), may be used to send meta-data thatprovides descriptive information about a file or application beingtransmitted. Examples of such descriptive information may includeattribute information such as name, size, and data type, as well asstructural information such as length of fields, location of data, andhow the data is associated with other data. The control channel 212 mayremain open across multiple file transfer sessions to avoid the need forrepeated connection establishment and termination.

The data channel 214 may utilize one or more of a variety of multicastprotocols for multicast data delivery. To conserve network resources,the data channel 214 may remain open only during the transmission ofdata and may be closed after a transmission has ended. The multicastprotocol selected may be, for example, a pragmatic general multicast(PGM) protocol as specified in the Internet Engineering Task Force(IETF) Request for Comment (RFC) 3208 entitled, “PGM Reliable TransportProtocol Specification.” The PGM protocol may enable a receiver of amulticast session to detect unrecoverable data loss. Unlike unicastprotocols such as TCP, which utilize positive acknowledgments (ACKs) toguarantee reliable data delivery, PGM uses a negative acknowledgment(NAK) and negative acknowledgment confirmation (NCF) system to alert theserver when data is not delivered. Unicast protocol ACKs may addexcessive traffic to a network, especially for sessions transmitted fromone server to many clients. By comparison, PGM does not contributeheavily to network congestion because NAKs are only generated when datais not received, and NCFs limit redundant NAKs. However, PGM does notprevent a client from experiencing unrecoverable data loss, nor does PGMprovide a mechanism for minimizing the retransmission of lost data.

Referring now to FIG. 3 a, in another embodiment, a method 300 enablesreliable data multicasting from a server to one or more clients withminimum retransmissions. The method begins, at step 302, when a client(e.g., the client 206 of FIG. 2) communicates an interest in receiving atransmission from a server (e.g., the server 204 of FIG. 2), therebyestablishing a control channel (e.g., the control channel 212 of FIG. 2)between the client and the server. A transmission may include multiplefiles, and the files may include multiple data packets. At step 304, theclient 206 is enrolled into a scoreboard (FIG. 4) used by the server 204for file transmission.

With additional reference to FIG. 4, a scoreboard 400 includes anidentity 402 of each client 206. The identity may be, for example, aninternet protocol (IP) address or other identifier associated with theclient 206, such as a media access control (MAC) number. Uponenrollment, the client 206 may become a member of a permanenttransmission group 404 which includes clients who have expressed aninterest in receiving the file transmissions by establishing a controlchannel connection. In the present example, the Boolean character “1”indicates membership in the group, and the character “0” indicates thata particular client's IP address is not a member of the group.Initially, the client 206 may also become a member of a currenttransmission group 406. Membership in the current transmission group 406may be indicated using the Boolean scheme described above. The currenttransmission group 406 may include clients 206 toward whom the server'scurrent session is directed. The server 204 may periodically scan thecontrol channel 212 for each client 206 to confirm client connectivity.

Referring again to FIG. 3 a, at step 306, all members of the permanenttransmission group 404 (FIG. 4) are made members of the currenttransmission group 406 (FIG. 4). The server 204 may confirm that allmembers of the current transmission group 406 are connected using thescoreboard 400 or another method. At step 308, the server 204 mayannounce the upcoming transmission over the control channel 212 to allpermanent transmission group members. The announcement may include thenumber of files to be transferred, a filename or filenames, the numberof byte ranges to be transmitted for each filename, and the starting andending bytes for each of the byte ranges to be transmitted in thesession. Proceeding to step 310, the clients 206 comprising the currenttransmission group 406 may begin listening on a data channel (e.g., thedata channel 214 of FIG. 2). At step 312, the server 204 begins thetransmission of the file over the data channel 214, and at step 313 theprocess of reliable file reception begins.

Referring now to FIG. 3 b, a method 314 for reliable file receptionbegins at step 316 with the clients 206, which are members of thecurrent transmission group 406, receiving the transmission over the datachannel 214. Proceeding to step 318, if the file is received in itsentirety by each client 206, the client proceeds to step 322 andcontinues to receive the additional files in the transmission. Becausethe client 206 has received the announcement as described in step 308,the client may be aware of the expected bytes to be delivered. Theclient 206 may compare the expected byte ranges to the received byteranges to determine whether the file was received in its entirety. Ifthe file is incomplete, the client 206 records the bytes correspondingto the missing data packets at step 320 and continues receiving thetransmission at step 322. If, for example, PGM is the protocol utilizedfor the data channel, missing data packets that cannot be restored causethe client 206 to detect an unrecoverable data loss. PGM allows theclient 206 to record information about the missing data packets using anoption of the protocol, OPT_FRAGMENT. This option allows the client 206to know the amount of missing data and the byte off-set where that datapacket belongs in the file, while continuing to receive transmissions.

At step 324, the client 206 may detect the end of the transmission byreceiving an end-of-file (EOF) indicator from the server 204. The client206 then closes the session on the data channel 214, and at step 326,communicates to the server 204 over the control channel 212 the missingbyte ranges not received in the data transmission of step 312. Thecommunication may include the client's IP address, the number of filesto be transferred, the file name or names, the number of missing byteranges for each filename, and the starting and ending byes for themissing byte ranges. The communication from the client 206 to the server204 over the control channel 212 may also include any ACKs or NAKsrequired by the multicast protocol. If, at step 328, the client 206 hasreceived the transmission in its entirety, the missing byte range may beindicated as NULL, which may serve as an acknowledgement to the server204 that the transmission was received. If the missing byte range isNULL, the client 206 may be removed from the current transmission group406 at step 330, but at step 332 may continue listening on the controlchannel 212 for announcement of the next transmission session. If, atstep 328, the missing byte range is something other than NULL, theretransmission process begins.

At step 334, the server 204 aggregates the missing byte ranges receivedfrom all clients 206, and determines the minimum superset of the missingbyte ranges for retransmission. At step 336, the server 204 announcesthis minimum superset for retransmission over the control channel 212.Responsive to the announcement over the control channel 212, a client206 listening on the control channel and interested in theretransmission may select whether to reestablish a data channel 214connection at step 338. The current transmission group 406 of thescorecard 400 is updated to include the clients 206 which havereestablished the data channel 214 for the retransmission. Because onlythe interested clients 206 connect for the retransmission based upon theannouncement over the control channel 212, data may not be carried toclients 206 that are not interested in the data. The server 204 maythen, at step 340, begin transmitting at least a portion of the originaltransmission, which may be the minimum superset of the missing byteranges, to the members of the current transmission group 406 over theestablished data channel 214. At step 342, the clients 206 receiving theretransmission select from the retransmission only the bytes which werenot received in the prior transmission. The steps 318 to 342 may berepeated until no clients exist in the current transmission group 406.

The methods 300 and 314 may be used for the multicast transmission of avariety of data. The transmission can, for example, include music files,financial data, movie videos, support packs, security bug fixes in anetwork management system, web content, or other content of interest tomultiple clients or desired by multiple clients simultaneously.

The methods described in FIGS. 3 a and 3 b may also be used toaccommodate a client who joins the permanent transmission group 404after a transmission has begun. The client may be made a member of thecurrent transmission group 406 and may receive an announcement for thesession over the control channel. This announcement may include afilename, the number of byte ranges, and the starting and ending bytesfor each of the byte ranges to be transmitted in the session. When theclient connects to the server on a data channel and begins receiving thetransmission of the session, the client may know and record the missingbytes based upon the control channel announcement. The client may thenrecover the missing bytes as described in FIG. 3 b.

If a client disconnects during a transmission, the client may be removedfrom both the permanent transmission group and current transmissiongroup. If a client disconnects while not a member of a currenttransmission group, the client may still be removed from the permanenttransmission group.

The methods 300 and 314 may also be used for multicasting in selectedtiers of a tiered electronic distribution (TED) application which allowsone server to distribute data files, server applications, or other typesof data to multiple subscribing servers. Still another application forthe methods 300 and 314 is reliable content delivery within a contentdistribution network (CDN). CDNs provide a method of alleviating networkcongestion by caching and serving web site content from servers near theclient rather than from the server of origin. The methods 300 and 314may also be used to transmit multicast data from a central office to abranch office using a branch office management appliance.

The methods 300 and 314 may also incorporate forward error correction(FEC) software which may reduce the number of retransmissions byalleviating some portion of the data packet loss. FEC software may beused with the original transmission and/or may be used with subsequentretransmissions.

While the preceding description shows and describes one or moreembodiments, it will be understood by those skilled in the art thatvarious changes in form and detail may be made therein without departingfrom the spirit and scope of the present disclosure. For example, thetype of protocols used in the preceding description may vary, and it isunderstood that substitutions may be made. Similarly, different networkconfigurations may be used for different types of digital devices.Therefore, the claims should be interpreted in a broad manner,consistent with the present disclosure.

1. A method for receiving multicast data, the method comprising:receiving at a computer a multicast data transmission over a multicastdata channel; sending from the computer a response over a controlchannel identifying data not received by the computer during themulticast data transmission; and receiving at the computer aretransmission, wherein the retransmission includes at least a portionof the data not received by the computer during the multicast datatransmission.
 2. The method of claim 1 further comprising: receivingmetadata about either the multicast data transmission or theretransmission.
 3. The method of claim 2, wherein the metadata includesat least one identifier corresponding to a byte range to be transmitted.4. The method of claim 2, wherein the metadata includes an IP addresscorresponding to a computer acting as a server.
 5. The method of claim1, wherein the multicast data transmission is associated with a first IPaddress, wherein the retransmission is associated with a second IPaddress, and wherein the first and second addresses are different. 6.The method of claim 1, wherein the computer also acts as a server,wherein acting as a server includes sending from the computer asecondary data transmission.
 7. The method of claim 6 wherein thesecondary data transmission includes a byte range previously received bythe computer.
 8. The method of claim 6, wherein the secondary datatransmission is sent over the multicast data channel.
 9. A method forsending multicast data, the method comprising: sending a multicast datatransmission over a multicast data channel; receiving a response over acontrol channel identifying a subset of the data sent during themulticast data transmission; and sending a retransmission, wherein theretransmission includes at least a portion of the data identified in theresponse.
 10. The method of claim 9 further comprising: sending metadataabout one of the multicast data transmission and the retransmission. 11.The method of claim 10, wherein the metadata includes at least oneidentifier corresponding to a byte range to be transmitted.
 12. Themethod of claim 10, wherein the metadata includes an IP addresscorresponding to a computer acting as a server.
 13. The method of claim10, wherein the metadata is sent from a first computer and wherein atleast one of the multicast data transmission and the retransmission issent from a second computer.
 14. The method of claim 9 wherein themulticast data transmission is sent from a first computer, and whereinthe retransmission is sent from a second computer.
 15. A method forreceiving multicast data, the method comprising: receiving at a computera first data transmission, the first data transmission including aplurality of byte ranges; identifying a byte range not received duringthe first data transmission; sending over a control channel a requestfor the identified byte range; and receiving at the computer a seconddata transmission, wherein the second data transmission includes theidentified byte range; wherein one of the first and second datatransmissions is received over a multicast data channel.
 16. The methodof claim 15 further comprising: receiving at the computer metadata abouteither the first or second data transmission.
 17. The method of claim16, wherein the metadata includes at least one identifier correspondingto a byte range.
 18. The method of claim 16, wherein the metadataincludes an IP address corresponding to a second computer.
 19. Themethod of claim 15, wherein the first data transmission is associatedwith a first IP address, and wherein the second data transmission isassociated with a second IP address.
 20. The method of claim 15, whereinthe computer also acts as a server, wherein acting as a server includessending from the computer a third data transmission.
 21. The method ofclaim 20, wherein the third data transmission includes a byte rangepreviously received by the computer.
 22. The method of claim 20, whereinthe third data transmission is sent over the multicast data channel.